Re: [HACKERS] Daemon News article - Mailing list pgsql-hackers
From | Henry B. Hotz |
---|---|
Subject | Re: [HACKERS] Daemon News article |
Date | |
Msg-id | v04020a06b3761fecd000@[137.78.84.130] Whole thread Raw |
In response to | Re: [HACKERS] Daemon News article (Bruce Momjian <maillist@candle.pha.pa.us>) |
Responses |
Re: [HACKERS] Daemon News article
Re: [HACKERS] Daemon News article |
List | pgsql-hackers |
At 3:28 PM -0700 5/29/99, Bruce Momjian wrote: >> The quote from Jolly Chen does not seem consistent with Eric Raymond's > >I totally agree that it is inconsistent, but I have never felt Rayond >was 100% correct. While I don't believe developers should have a >'holier than thow' attitude (and I don't think we have), most patches >from people who did not take the time to figure out how things worked >were a disaster if applied. If we don't have reliability, we have >nothing in the db world, and a bazzar is not reliable. > I don't think Eric is claiming that a bazzar is ideal, just that there are enormous advantages to going ahead and releasing code which isn't quite done. Once you have a good framework set up an awful lot of people can help with the detail debugging. A really good test case is 90% of a complete fix. 25 years ago I observed that part of the IBM monopoly was based on how *bad* their stuff was. It was so difficult to get things working that by the time you did you were afraid to do it over with another company. And you were kind of proud of the fact that you *did* get it working in the end after all. In my opinion, Microsoft has done a similarly masterful job of making things just good enough that the competition wasn't obviously better, while making their stuff bad enough to maximize the required custommer commitment. This paragraph is intended as a side observation, not flame bait. Perhaps the point to make in the paper is just that we have chosen a particular development cycle/philosophy. It doesn't happen to coincide precisely with Eric Raymond's recommendations, but we're not exactly a cathedral either. --------------- Responding to what Bruce wrote while I was writing this note: I don't entirely agree with the comment about gcc. Before egcs they generally had a "stable" release, e.g. 2.5.8, or 2.6.3, or 2.7.2.x that was being widely used while there was also a "current" release like 2.6.1, or 2.7.1, or 2.8.0. In their case there was also an internal-only alpha/beta version which we never saw. Coming from this background I found it difficult to evaluate the stability of various Postgres versions because there was no parallel maintenance of a "stable patched" version independent of the "development" version. I still feel it is unfair to expect all developers to "switch gears" between just fixing bugs and just developing new stuff in order to conform to a single release cycle. Some people are better at one than the other. Likewise I think our users would welcome a choice between a known stable version and a more featureful current version. I'm not sure our beta versions quite provide this kind of distinction. But at this point I am commenting randomly on actual deveopment policy rather than on the article. Signature failed Preliminary Design Review. Feasibility of a new signature is currently being evaluated. h.b.hotz@jpl.nasa.gov, or hbhotz@oxy.edu
pgsql-hackers by date: